Entwicklung eines RDF Stores
Milestone 3: Endabgabe
Abgabefrist: Mo, 21.07.2008, 09:00 Uhr (morgens)Testanfragen
Die folgenden Testanfragen dienen zum Testen des Auswertungsmoduls. Die Anfragen sind in der eingeführten GraphPattern-Syntax, sowie in SPARQL-Syntax verfügbar. Während die GraphPattern-Queries zum Testen eurer Implemtierung dienen, können die SPARQL-Queries zum Vergleich der Ergebnisse, d.h. zur Überprüfung der Korrektheit, genutzt werden: sie können beispielsweise mit der ARQ SPARQL Engine ausführt werden. Euer Programm sollte in der Lage sein, alle Queries zumindest auf den beiden kleinsten Dokumentgrößen (ungefähr 10k und 50k Tripel) auszuwerten und dabei (in Einzelfällen) höchstens wegen zu hohem Hauptspeicherverbrauch oder zu langer Auswertungsdauer erfolglos bleiben. Insbesondere sollten in keinem Fall inkorrekte Ergebnisse berechnet werden. Download:- Queries in GraphPattern-Syntax zum Testen eurer Implementierung (upgedatet 16.07.2008)
- Queries in SPARQL-Syntax zum Ergebnisvergleich (upgedatet 18.07.2008)
- Dokumente (in N3-Format); Achtung: die .zip-Datei ist ungefähr 13MB groß; alternativ könnt ihr die Eingabedokumente auch lokal auf eurem Rechner mit Hilfe des SP²Bench-Datengenerator mittels der drei Befehle "sp2b_gen -t 10000", "sp2b_gen -t 50000", und "sp2b_gen -t 1000000" erzeugen (je ein Befehl dient zum Erzeugen einer Dokumentgröße).
Die Ergebnisgrößen der Anfragen sind in folgender Tabelle zusammengefasst und können zum groben Überprüfen eurer Engine benutzt werden. Natürlich sollten die Ergebnisse auch detailliert abgeglichen werden. Alle Ergebnisse wurden von uns mit Hilfe der ARQ SPARQL-Engine auf den SPARQL-Anfragen ermittelt (sollten eure Ergebnisse auch nach sorgfältiger Prüfung von den in der Tabelle aufgeführten abweichen und ihr der Meinung sein dass eure Engine das richtige Ergebnis liefert benachrichtigt uns bitte per Mail).
| Q1 | Alle RDF-Tripel | |||
| Q2 | Alle Journale | |||
| Q3 | Alle Journale, die vor dem Jahr 1970 erschienen sind | |||
| Q4 | Alle Autoren mit Erdös-Nummer 1, die zwischen 1955 und 1965 publiziert haben | |||
| Q5 | Alle Publikationen vom Typ Inproceedings mit den Eigenschaften dc:creator, bench:booktitle, dcterms:issued, dcterms:partOf, rdfs:seeAlso, dc:title, swrc:pages, foaf:homepage und optional bench:abstract, incl. den entsprechenden Werten | |||
| Q6 | Ausgehende und eingehende Kantenbeschriftungen von Personen, incl. der Personen | |||
| Q7 | Jahr, in dem die Publikation "Journal 1 (1940)" erschienen ist | |||
| Q8 | Alle Artikel mit Titel von denen bekannt ist, dass sie in den Monaten Januar bis Juni veröffentlicht wurden | |||
| Q9 | Alle Personen, die in unterschiedlichen Jahren als Editor tätig waren (inclusive den entsprechenden Jahreszahlen) | |||
| Q10 | Existiert eine Person mit der URI <http://localhost/persons/John_Q_Public>? | |||
Abgabemodus
- Die Abgabe erfolgt per SVN, d.h. über das Einchecken der aktuellen Version. Insbesondere sollte diese Version alle verwendeten Libraries enthalten, d.h. ohne die zusätzliche Installation von Libraries (wie Jena, BerkeleyDB) direkt lauffähig sein.
- Bitte testet den vorigen Punkt explizit, indem ihr die Sourcen auf einen (möglichst bisher unbenutzten) Rechner auscheckt und dort testet, ob alles problemlos läuft.
- Es sollte selbstverständlich sein, dass der Source Code ohne Fehler kompilierbar ist.
- Das Projekt muss ohne Modifikationen am Source Code alle Optionen unterstützen, d.h. vollständig über Kommandozeile bedienbar sein.
- Das Projekt besitzt genau eine Main-Methode; die einzelnen Module (sprich Laden der Daten in die Datenbank und Auswerten von Anfragen) können über entsprechende Kommandozeilenparameter aktiviert werden.
- Die Ausgabe der Ergebnisse bei der Evaluierung von Graph-Patterns erfolgt in eine CSV-Datei (vergleiche Folien Graph Pattern Semantics, S. 20-21). Insbesondere soll es in der Ausgabedatei eine Kopfzeile geben (in der die Variablennamen definiert sind) und genau eine Zeile pro Mapping in der Lösungsmenge.
- Zusätzlich zur eingecheckten Version sendet jedes Team eine Datei (wahlweise MS Word, OpenOffice oder PDF) vor Ende der Deadline per Mail parallel an beide Betreuer. Diese Datei ist wie folgt in genau fünf Kapitel untergliedert:
- Kapitel 1: Installations- und Bedienungsanleitung
Hier solltet ihr in wenigen Sätzen die Kommandozeilenparameter erklären, die zum Ausführen notwendig sind (Laden und Auswerten) und - wenn nötig - eine kurze Installationsanleitung geben. - Kapitel 2: Klassenauflistung und Aufgabenverteilung
Dieses Kapitel enthält eine stichwortartige Auflistung aller Klassen die im Projekt vorhanden sind. Zu jeder Klasse sind die folgenden Informationen anzugeben:- Klassenname,
- Klassenbeschreibung (in einem Satz kurz und präzise beschreiben, welche Funktion diese Klasse hat),
- Hauptverantwortliche(r),
- Nebenverantwortliche(r).
- Kapitel 3: Implementierte Features und Eigenschaften
In diesem Kapitel sollen die folgenden Fragen kurz und präzise beantwortet werden:- Unterstützt euer Programm Statistiken? Wenn ja, in welchem Umfang?
- Kommt euer Programm mit konstantem Speicherverbrauch aus? Sind solche Strategien ansatzweise implementiert? Wenn ja, wie?
- Welche Arten von Joins wurden implementiert? Nested Loop Joins? Merge Joins? Andere Join-Typen?
- Enthält euer Programm sonstige besondere Features?
- Kapitel 4: Testergebnisse
Dieses Kapitel enthält eine tabellarische Auflistung der Testergebnisse für alle Testanfragen auf allen Dokumentgrößen. Für jede Testanfrage und Dokumentgröße soll in tabellarischer Form angegeben werden, ob die Testanfrage erfolgreich (S) war, aufgrund zu langer Laufzeit (T, beispielsweise länger als 30min) oder zu hohem Speicherverbrauch (M) abgebrochen wurde, oder einem sonstigen Fehler (E) geliefert hat. Bitte beachtet dass laut Anforderung an die Testanfragen oben keine E's in eurer Ergebnismatrix vorkommen sollten. Zusäztlich soll das Kapitel eine kurze Spezifikation der Hardware/Software enthalten, auf der die Anfragen getestet wurden (CPU, RAM, Java Version etc.). Da das Anfertigen der Testergebnisse mit Aufwand verbunden ist, möchten wir euch bitten zu vermerken, wer diese Aufgabe in eurer Gruppe übernommen hat. - Kapitel 5: Sonstiges
In diesem Kapitel ist Platz für sonstige Anmerkungen. Insbesondere könnt ihr vermerken, wer zusätzlichen Aufwand für nicht-programmiererische Aufgaben (wie z.B. Koordination, Erstellen dieser Dokumentation, etc.) hatte.
- Kapitel 1: Installations- und Bedienungsanleitung
Bewertungskriterien
Um spätere Missverständnisse aus dem Weg zu schaffen hier eine kurze Auflistung der Kriterien, die wir zur Bewertung heranziehen werden. Die Liste erhebt keinen Anspruch auf Vollständigkeit.- Ausschlaggebend für die Gesamtbewertung des Projekts ist die Korrektheit.
- Zusätzlich zu den verlinkten Testanfragen werden wir noch einige nicht-öffentlich Testanfragen durchführen. Vom Schwierigkeitsgrad her sind diese Anfragen vergleichbar mit den oben verfügbaren Graph Patterns. Dennoch empfiehlt es sich, zusätzlich zu den obigen Tests eigene Anfragen zu entwerfen und zu testen.
- Das Laden der Dokumente muss mit konstantem Hauptspeicherverbrauch erfolgen.
- Zusätzliche Features (wie konstanter Speicherverbrauch, Nutzung von Statistiken etc.) wirken sich positiv auf die Bewertung aus.
- Auf individueller Ebene werden insbesondere (jedoch nicht ausschließlich) die folgenden Kriterien eine Rolle bei der Bewertung spielen: Umfang des persönlichen Beitrags zum Projekt (jeweils gemessen an den Anforderungen für Bachelor- und Masterstudenten), Schwierigkeitsgrad der implementierten Klassen, Einarbeitungsaufwand in die verschiedenen Bereiche, Code-Struktur (Lesbarkeit, Nachvollziehbarkeit, Design, ...).
- Der erfolgreiche Abschluss ist im Sinne eines Teamprojekts auch als individueller Erfolg zu werten und wird sich selbstverständlich positiv auf die Bewertung aller Gruppenmitglieder auswirken!